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Reply to Office Action 

REMARKS 

The Examiner is thanked for the performance of a thorough search. 
No claims have been added, cancelled, or amended. Hence, Claims 1-18 are pending in 
the application. 

I. SUMMARY OF THE REJECTIONS 

Claims 1-18 have been rejected under 35 U.S.C. § 102(e) as allegedly being anticipated 
by Rich et al., U.S. Patent No. 6,457,065 ("RICH"). 

n. REJECTIONS BASED ON THE PRIOR ART 
A. CLAIMS 1 AND 10 
Claims 1 and 10 recite the following features: 

receiving a command to perform one or more file system operations; 

in response to said command, performing a plurality of operations including 

said one or more file system operations; 
wherein the step of performing the plurality of operations includes: 

performing a first subset of said plurality of operations as part of a 

first transaction; and 
performing a second subset of said plurality of operations as part of a 
second transaction that is nested in said first transaction. 

Thus, Claims 1 and 10 expressly recite the features of receiving a command to perform 
one or more file system operations, and performing a plurality of operations including the one 
or more file system operations, where a first subset of the plurality of operations is performed as 
part of a first transaction, and a second subset of the plurality of operations is performed as part 
of a second transaction that is nested in the first transaction. The Applicants respectfully 
submit that none of these features is disclosed, taught, or suggested by RICH. 



2 

Docket No. 50277-1561 (OID 2000-068-01) 



Application of David LONG, et al 9 Serial No. 09/853,823, Filed May 11, 2001 

Reply to Office Action 

1. The rejection of Claims 1 and 10 in the Office Action 
For the elements in Claims 1 and 10 and for the elements of many other claims, the 
Office Action provides broad citations of whole columns in RICH and does not specify exactly 
what in the RICH reference corresponds to or constitutes each element or feature of the claims. 
In an Office Action "the particular part relied on must be designated as nearly as practicable . . . 
The pertinence of each reference, if not apparent, must be clearly explained . . (MPEP §707, 
citing 37 C.F.R. §1.1 04(c)(2)), and "the particular figure(s) of the drawings(s), and/or page(s) or 
paragraph(s) of the reference(s), and/or any relevant comments briefly stated should be 
included." (MPEP §707). The present citations to RICH do not provide the Applicants with 
adequate notice or reasonable particularity with respect to the basis of the rejections. Instead, 
large portions of RICH are simply identified in a non-specific way. As a result, the Applicants 
have had to engage in guesswork to determine the basis of the rejection. In particular, in 
regards to Claims 1 and 10, the Applicants cannot see any structure or functions in RICH that 
correspond to the features in these claims. As best understood by the Applicants, the Office 
Action makes an extremely broad, and technically incorrect, analogy between replicating 
objects in a distributed object-oriented system and performing file system operations in a file 
system. 

RICH deals with improving the performance of distributed object systems by providing 
techniques for efficient replication of objects among the nodes of the distributed system. 
(Abstract.) The objects in the distributed object system may have several instances that reside 
on different nodes. An object is described with respect to existing object distribution 
techniques, such as Enterprise Java Beans (EJB), and Common Object Request Broker 
Architecture. (Col. 1, lines 40-45.) Thus, RICH teaches that the term "object" carries its 
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ordinary meaning as understood in the art, which is an instantiated object-oriented class that 
encapsulates object properties and/or object data with the procedures that operate on the object 
properties and/or object data. (See col. 1, line 60 to col. 2, line 8.) Nothing in RICH describes, 
teaches or suggests that the term "object" is used to mean anything but this ordinary meaning, 
let alone suggest that somehow "object" is used to describe an element of a file system, and that 
a distributed object system is somehow analogous to a file system. Furthermore, RICH does 
not teach, describe or suggest that its techniques for replicating objects among distinct nodes in 
a distributed system apply in anyway to file system operations performed in a file system. 

2. RICH fails to teach receiving a command to perform one or more file system 

operations and performing a plurality of operations including the one or more 

file system operations 

The Office Action asserts that the paragraph in RICH, in col. 7, line 53 to col. 8, line 18 
teaches "receiving a command to perform one or more file system operations", and "performing 
a plurality of operations including said one or more file system operations." The Applicants 
respectfully disagree. 

In col. 7, line 53 to col. 8, line 18, RICH states the following: 

According to the present invention, the scope of the replication is a transaction. 
What constitutes a transaction is an application-dependent decision. Using 
commonly-known industry terms, a transaction represents a logical group 
changes to one or more objects that will be performed in an atomic manner (that 
is, either all operations within the transaction are performed, or none of them are 
performed). U.S. patent application Ser. No. 09/001,980, titled "Technique for 
Managing Objects which are the Target of Multiple Transactions in a 
Client/Server Environment" (hereinafter, "the first related invention"), defines a 
technique for using a transactional approach to maintain consistency in updating 
objects, where the tasks a user (or application program) performs are organized 
into transactions. Using the transactional approach defined in this first related 
invention, all changes that the user wants to make to an object within the scope 
of a transaction are made first to an internal copy (called a "version") of the 
object, without actually updating the persistent, stored object itself. The user 
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eventually decides whether to permanently commit the changes encompassed by 
the transaction, or whether to discard them. If the user chooses to commit, then 
the updated object in the version is copied to the persistent store. If the user 
chooses to discard (or "roll back") the changes, the persistent store is unchanged. 
(The concept of persistent store is well known, and will not be described in 
detail herein. In a client/server or multi-tier environment, a persistent store of 
objects may be maintained in or one or more locations which are accessible by 
applications in the computing environment, such as one or more common 
databases. Such databases may be maintained in, for example, the data 
repository 348 of FIG. 3 or the long term storage 230 of FIG. 2.) 

The paragraph recited above describes a transactional approach to maintain consistency in 
updating objects located on different nodes of a distributed system, but does not describe, teach 
or suggest "receiving a command to perform one or more file system operations", let alone 
describe "performing a plurality of operations including said one or more file system 
operations" as recited in Claims 1 and 10. Furthermore, the Applicants find nothing else in 
RICH that may even remotely describe, teach, or suggest that the transactional approach in 
RICH relates to any operation other than the operation of updating an object. 

3. RICH fails to teach performing a first subset of the plurality of operations as 
part of a first transaction and performing a second subset of the plurality of 
operations as part of a second transaction that is nested in the first transaction 
The Office Action asserts that the features of "performing a first subset of said plurality 
of operations as part of a first transaction" and "performing a second subset of said plurality of 
operations as part of a second transaction that is nested in said first transaction" are disclosed in 
col. 7, line 53 to col. 8, line 18, and further in col. 8, line 63 to col. 9, line 40. The Applicants 
respectfully disagree. 

As discussed above, in col. 7, line 53 to col. 8, line 18 RICH describes a transactional 
approach to maintain consistency in updating objects located on different nodes of a distributed 
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system, but does not describe or suggest that such an approach may be relevant to performing 

operations in a file system. In col. 8, line 63 to col. 9, line 2, RICH generally describes a 

distributed computer system in which nodes may act as both clients and servers. Further, RICH 

describes that a transaction may exist across many nodes or within a node. (Col. 9, lines 2-3). 

Significantly, in col. 9, lines 2-12, RICH states that 

The logical transaction model for a replicated distributed object system, as 
defined by the present invention, forms a tree of nested transactions. A physical 
node may have nodes of transaction trees for multiple transactions, and may be a 
parent for some transactions while being a child for other transactions. The 
present invention uses these nested transactions trees to manage changes to 
the replicas, as well as actual changes to remote objects in the persistent 
store, resulting from one or more concurrent and/or nested transactions. 

The rest of the paragraph asserted by the Office Action as disclosing features of Claims 1 and 
10, namely col. 9, lines 12-40, describes nested transactions in terms of logical trees where 
nested transactions are represented as tree branches and flat transactions are represented as tree 
leafs. 

Thus, nothing in col. 8, line 63 to col. 9, line 40 in RICH teaches, suggests, or describes 
the features of Claims 1 and 10 that require "performing a first subset of said plurality of 
operations as part of a first transaction" and "performing a second subset of said plurality of 
operations as part of a second transaction that is nested in said first transaction." To the 
contrary, the portion of RICH highlighted above suggests that RICH discloses use of nested 
transactions exclusively for managing changes to replicated objects (or replicas) and changes to 
remote objects in persistent store. Nothing in RICH describes, teaches, or even remotely 
suggests that nested transactions may be used to manage any file system operations. 
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For these reasons, the Applicants respectfully submit that RICH does not describe, 
. teach, or suggest any of the features recited in Claims 1 and 10. Thus, withdrawal of the 
rejection of Claims 1 and 10 under 35 U.S.C. § 102(e) over RICH is respectfully requested. 

B. CLAIMS 4 AND 13 

Claims 4 and 13 are dependent upon Claims 1 and 10, respectively, and thus include 
each and every feature of the corresponding independent claims. Therefore, it is respectfully 
submitted that Claims 4 and 13 are allowable for at least the reasons given above with respect 
to Claims 1 and 10. 

In addition, Claims 4 and 13 recite the following additional novel features: 

the step of receiving the command is performed by an entity that resides external to a 
database server; and 

the step of performing said plurality of operations includes said entity sending database 
commands to said database server. 

The Office Action asserts that RICH discloses these features in col. 7, line 53 to col. 8, line 18, 

and in col. 11, lines 21-35. The Applicants respectfully disagree. 

As discussed above, nothing in RICH, including the paragraph in col. 7, line 53 to col. 

8, line 18, teaches or even remotely suggests that nested transactions may be used to manage 

file system operations. Furthermore, the paragraph in col. 11, line 21-35, fails to teach that an 

entity other than a database server receives a command to perform one or more file system 

operations, and that a database server performs a plurality of operations that include the one or 

more file system operations. The paragraph in col. 11, lines 21-35 states: 

Transactions whose parent resides in a different node of the distributed object 
system consist of two components: the "server transaction" in the parent node 
' and the "current transaction" in the client node. This is illustrated by the 
example in FIG. 4B, where node 460 has the top-level transaction 470 and two 
children 471, 472 which are siblings. Child transaction 471 is designated as a 
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"server child transaction", because it has a child transaction 473 (which is 
designated as a "client child transaction") on client node 462. Client child 
transaction 473 then has two children 474, 475 in this example. A root node of a 
client transaction (such as node 473) serves as the parent transaction for the 
scope of the client node, but is a child of the server transaction (such as node 
471). A reference to a parent transaction in a remote node is called a 
"transaction proxy." 

The Applicants fail to find anything in this paragraph, or for that matter, anything in RICH, 
which even remotely suggests the feature of Claims 4 and 13 requiring that the step of receiving 
a command to perform one or more file system operations is performed by an entity other than a 
database server. Furthermore, the Applicants have not found anything in RICH that is even 
remotely related to a feature in which a database server performs a plurality of operations that 
include one or more file system operations, let alone teach that a subset of the plurality of 
operations may be performed as a transaction that is nested in another transaction that includes 
another subset of the plurality of file system operations. 

For these reasons, the Applicants respectfully submit that RICH does not describe, 
teach, or suggest any of the features recited in Claims 4 and 13. Thus, withdrawal of the 
rejection of Claims 4 and 13 under 35 U.S.C. § 102(e) over RICH is respectfully requested. 

C. CLAIMS 2-3, 5-9, 11-12, AND 14-18 

Each of Claims 2-3, 5-9, 1 1-12, and 14-18 is dependent upon one of independent 
Claims 1 and 10, and thus includes each and every feature of its corresponding independent 
claim. Each of Claims 2-3, 5-9, 11-12, and 14-18 is therefore allowable for the reasons given 
above for Claims 1 and 10. In addition, each of Claims 2-3, 5-9, 11-12, and 14-18 introduces 
one or more additional features that independently render it patentable. However, due to the 
fundamental differences already identified, to expedite the positive resolution of this case a 
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separate discussion of those features is not included at this time. Therefore, it is respectfully 
submitted that Claims 2-3, 5-9, 11-12, and 14-18 are allowable for the reasons given above with 
respect to Claims 1 and 10. 

m. CONCLUSION 

The Applicants believe that all issues raised in the Office Action have been addressed. 
Further, for the reasons set forth above, the Applicants respectfully submit that allowance of the 
pending claims is appropriate. Reconsideration of the present application is respectfully 
requested in light of the remarks herein. 

The Examiner is respectfully requested to contact the undersigned by telephone if it is 
believed that such contact would further the examination of the present application. 

To the extent necessary to make this reply timely filed, the Applicant petitions for an 
extension of time under 37 C.F.R. § 1.136. If any applicable fee is missing or insufficient, 
throughout the pendency of this application, the Commissioner is hereby authorized to charge 
any applicable fees and to credit any overpayments to our Deposit Account No. 50-1302. 



Respectfully submitted, 



HICKMAN PALERMO TRUONG & BECKER LLP 



Dated: December 22, 2004 




Stoycho D. Draganoff 
Reg. No. 56,181 



2055 Gateway Place, Suite 550 
San Jose, California 95110-1089 
Telephone No.: (408) 414-1080 ext. 208 
Facsimile No.: (408) 414-1076 
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